Firstly, this is awesome and I'm very excited about this making its way into CodeCompanion.

I've done a first pass review. Nothing major, lots of nitpicking. Then I'll give it some proper testing over the holiday period.

Giving some thoughts to the UX, I think the distinction between MCP "tools" and regular tools, the former should be visible in the chat buffer as @{mcp.runPython}. It makes it easier for users to filter via their completion plugin and makes the distinction clear.

Seeing how you've implemented the MCP servers:

sequentialThinking = {
    cmd = { "npx", "-y", "@modelcontextprotocol/server-sequential-thinking" },
    tool_overrides = {
      sequentialthinking = {
        output = {
          success = function(self, tools, cmd, stdout)
            local output = stdout and stdout[#stdout]
            local msg = "Sequential thinking: " .. self.args.thought
            tools.chat:add_tool_output(self, output, msg)
          end,
        },
      },
    },
  },

Is brilliant 👏🏼. The tool_bridge.lua file is an excellent idea. Ideally, we wouldn't have sequentialthinking appear twice in the same config block but this can be tackled towards the end of the PR.

Seeing success = function(self, tools, cmd, stdout)...this is on me to refactor. I'm trying to move everything over to success = function(self, args) pattern as it's future proof should we add additional arguments. I realized this pattern far too late on. So heads up, this may change in the future.

Once again, thanks for this brilliant PR.

Pull request overview

This PR implements a basic MCP (Model Context Protocol) client for CodeCompanion, enabling integration with MCP servers to expose their tools as CodeCompanion tools. The implementation supports stdio transport, tool pagination, roots capability, and customizable tool behavior.

Key changes:

• Core MCP client with JSON-RPC communication over stdio transport
• Tool bridge to convert MCP tools into CodeCompanion tool format with grouping by server
• Comprehensive test coverage with mock transport for unit and integration testing

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 12 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Initial reaction:

This is awesome. Really, really awesome. The fact all I needed to do to get this working, was:

      mcp = {
        servers = {
          ["tavily-mcp"] = {
            cmd = { "npx", "-y", "tavily-mcp@latest" },
            env = {
              TAVILY_API_KEY = "cmd:op read op://personal/Tavily_API/credential --no-newline",
            },
          },
        },
      },

...is tremendous.

I've put some inline comments. Pretty much minor stuff now. I will write the docs and add some more test coverage (think we might need a bit of coverage around mcp servers appearing in the completion list).

There's a couple of (hopefully) small hurdles I've noticed:

• In my example above, I'm being prompted by 1Password everytime I create a new chat buffer. I may not want to add the Tavily MCP server to this chat buffer so think this prompt should be when I've pressed submit to send the response to the LLM.
• It can be hit-and-miss if the MCP server appears in the completion list in the chat buffer. I notice when I open a fresh Neovim, create a chat buffer, I often don't see the MCP servers. If I open a second chat buffer, I do see them. I think we may need to shift the logic of creating the MCP groups to the providers.completion.init file like we do for all other tools and groups.

Otherwise, this is amazing and I can't wait to merge this into CodeCompanion. No rush and take your time. We all have lives outside of open-source. And, if you need me to pickup any bits, just say.